home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20010921-20020314
/
000145_fdc@watsun.cc.columbia.edu_Sun Nov 11 14:14:08 EST 2001.msg
< prev
next >
Wrap
Text File
|
2020-01-01
|
3KB
|
51 lines
Article: 12965 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Hex operations in Kermit
Date: 11 Nov 2001 19:14:55 GMT
Organization: Columbia University
Lines: 34
Message-ID: <9sminf$c0h$1@newsmaster.cc.columbia.edu>
References: <I72H7.79555$Gh2.24053794@news2.rdc1.bc.home.com> <XIzH7.83484$Gh2.25452683@news2.rdc1.bc.home.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 1005506095 12305 128.59.39.2 (11 Nov 2001 19:14:55 GMT)
X-Complaints-To: postmaster@columbia.edu
NNTP-Posting-Date: 11 Nov 2001 19:14:55 GMT
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:12965
In article <XIzH7.83484$Gh2.25452683@news2.rdc1.bc.home.com>,
jens <psh@home.com> wrote:
: > C-Kermit allows me to send hex code out the serial port with the OUTPUT
: > \xnn command. I am looking for a way to receive hex strings, find a match
: > and do a task based on what hex string was received. I tried doing this
: > with MINPUT and the \xnn notation but Kermit is just splitting it's gut at
: > my feable attempts at this.
: > How would I go about testing for lets say two hex strings \xaa\xab and
: > \x3e\x12 and depending on which string it matches branching to a task
: > list.
:
: I received lots of help from Frank da Cruz (thanks again !!) and most of my
: testing for hex characters is working. It seems though that \x00 (nul) is a
: special case for some reason and testing for it does not succeed. Does
: anyone know a work-around for this ?
:
: As an example, my program might receive the following hex string:
: ab 04 cf 69 e8 d5 5c ab 03 93 00 00 bf
: and based on that needs to send out a reply.
:
C-Kermit is not called C-Kermit for nothing :-) It is a burden of C
programs that character strings are terminated by NUL bytes. To make a
C program "NUL-Clean" requires considerable effort, including foresaking the
use of all library and system calls that take string arguments. Too bad C
does not include strings as a native data type; if it had done so from the
beginning, we'd probably be landing humans on distant planets by now rather
than futzing with memory leaks, buffer exploits, etc, but I digress.
The inability to deal with NUL bytes transparently in INPUT and OUTPUT
commands is a well-documented restriction. There are ways to get around
it, described in the manual on pages 421-422 but they aren't pretty,
especially on the INPUT side.
- Frank